home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3862 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB
  1. Path: hydra.zrz.TU-Berlin.DE!rawneiha
  2. From: rawneiha@hydra.zrz.TU-Berlin.DE (Philipp Boerker)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Texture/Gouraud innerloop speedtests
  5. Date: 19 Feb 1996 14:38:55 GMT
  6. Organization: Technical University Berlin, Germany
  7. Message-ID: <4ga21v$lsk@brachio.zrz.TU-Berlin.DE>
  8. References: <38232464@kone.fipnet.fi>
  9. NNTP-Posting-Host: hydra.zrz.tu-berlin.de
  10.  
  11. "Jyrki Saarinen" <jsaarinen@kone.fipnet.fi> writes:
  12.  
  13.  
  14. >Ok, I did a little research. My CPU is a 40MHz 68040,
  15. >a Warp Engine with a very fast memory system, maybe
  16. >this is the reason I did not gain any speed even if
  17. >I turned the data cache and thus data burst off,
  18. >with data burst everything was about 50% slower.
  19.  
  20. Not very surprising! Data burst means that whenever
  21. a cache-miss occurs the CPU loads 4 longwords around
  22. the mem area where the data to be fetched is. For a
  23. tmapping loop this means that for almost any pixel that
  24. is fetched from the texture the CPU keeps the bus busy
  25. for 4 mem cycles!
  26.  
  27.  
  28. >So the frame rates were for a 320x256 screen:
  29. >Texture/Gouraud/Shading table, 64k aligned: ~43 fps
  30. >Plain Texture, 64k aligned: ~67 fps
  31.  
  32. fps? Are these figures for the mere repetition (320*256 times)
  33. of the innerloop?
  34.  
  35. >    move.b    (a3),d1
  36. >    move.l    d1,a3
  37. >    add.l    a2,a1
  38. >    move.b    (a3),(a0)+
  39. >    dbf    d7,poly
  40. >    rts
  41.  
  42. >The places were schedeling was most effective were the
  43. >        move.l  d0,a3
  44. >        <something here is a must>
  45. >        move.b  (a3),d1
  46. >        <or>
  47. >        move.b  (a3),(a0)+
  48.  
  49. >    move.b    (a3,d0.l),d1
  50. >    move.b    (a4,d1.l),(a0)+
  51.         [...]
  52. >    dbf    d7,poly
  53. >    rts
  54.  
  55. If I understand your problem right you wonder why the
  56. two version are almost equal in terms of speed? The scheduling
  57. is not optimal in both versions, you use the data that you
  58. fetch in the next instruction.
  59.  
  60. Greets,
  61. Phil.
  62.  
  63. grond/matrix
  64.  
  65.